I wonder if https://github.com/googleapis/release-please might just be a better option here. I'm going with that in filecoin-pin at the moment and we'll be switching synapse-sdk to it and it's fairly flexible, not tied to npm/node stuff. Maybe we can extend it with some hooks to do some updates for us - like update the version string in the contract for us based on conventional commits guessing. Worth looking at at least?

Yeah, I will take a look at that. And update accordingly.

Below are my thoughts @rjan90 around this subject. But maybe we should move this to a more general "FOC contract versioning and release management" design doc?

• For building up the changelog: I agree we should just lean in hard to conventional commits and linear history. This would mean:

  • Maybe only support squash/merge
  • Actually having a CI check to ensure PR title follows conventional commit and ensure that an attempted merge has a commit message that follows conventional commit (i.e., catch the case when someone changes the squash/merge message to not be the PR title).

• For creating the GitHub release with a release version number: release-please seems great here for this.

• For deployments of library contracts: I see we have various scripts in our repos for deploying to calibration and mainnet. My hope is that we have the ability to say "deploy contract [email protected] to calibraiton|mainnet" and then after a deployment a release artifact is attached to the github release itself. So basically https://github.com/FilOzone/pdp/releases/tag/v2.1.0 would have a "mainnet-deployment.json" file attached that has a deployment receipt like:

{
   networkName : "mainnnet",
   contractNameDeployed : "pdp.sol",
   commitDeployed : "commit_that_corresponds_with_version_2.1.0",
   contractAddress : "address_of_contract_on_mainnet",
   deploymentTransaction : "transaction_hash",
}

• For declaring dependencies on libraries: it looks like we're using git submodules per https://github.com/FilOzone/filecoin-services/blob/main/service_contracts/README.md#structure rather than a more declarative dependency management solution (npm/yarn). Going with submodules, maybe as part of our build process we output git submodule status to give more visibility to what version we're depending on?

• For deploying consuming contracts like filecoin-services: we modify the existing scripts such that if we're trying to deploy to mainnet, we look up the release artifact associated with the tag that shows up in the submodule. So for example, for PDP_VERIFIER_ADDRESS in https://github.com/FilOzone/filecoin-services/blob/main/service_contracts/tools/deploy-warm-storage-calibnet.sh, it would default to finding the release artifact associated with the tag of the commit of the pdp submodule.

General comments:

1. Maybe just personal taste, but I would avoid big inline scripts in the github action workflows. Instead externalize them and reference them in the workflow.
2. Also maybe personal taste, but I would vote for using something more human readable than large bash scripts (e.g., do a Node script) if there is much conditional / conditional structure or error handling required.

I won't claim expertise here and happy to support alternative approaches. This is where I landed with when trying to balance where we are with getting things more auditable and less error prone for the future.